3 research outputs found
Feature-based methodology for supporting architecture refactoring and maintenance of long-life software systems
Zusammenfassung
Langlebige Software-Systeme durchlaufen viele bedeutende Veraenderungen im Laufe ihres Lebenszyklus,
um der Weiterentwicklung der Problemdomaenen zu folgen. Normalerweise ist es schwierig eine
Software-Systemarchitektur den schnellen Weiterentwicklungen einer Problemdomaene anzupassen und
mit der Zeit wird der Unterschied zwischen der Problemdomaene und der Software-Systemarchitektur
zu groĂź, um weitere Softwareentwicklung sinnvoll fortzufuehren. Fristgerechte Refactorings der Systemarchitektur
sind notwendig, um dieses Problem zu vermeiden.
Aufgrund des verhaeltnismaeĂźig hohen Gefahrenpotenzials und des zeitlich stark verzoegerten Nutzens
von Refactorings, werden diese MaĂźnahmen normalerweise bis zum letztmoeglichen Zeitpunkt hinausgeschoben.
In der Regel ist das Management abgeneigt Architektur-Refactorings zu akzeptieren,
auĂźer diese sind absolut notwendig. Die bevorzugte Vorgehensweise ist, neue Systemmerkmale ad hoc
hinzuzufuegen und nach dem Motto ”Aendere nie etwas an einem funktionierenden System!” vorzugehen.
Letztlich ist das Ergebnis ein Architekturzerfall (Architekturdrift). Die Notwendigkeit kleiner
Refactoring-Schritte fuehrt zur Notwendigkeit des Architektur-Reengineerings. Im Gegensatz zum
Refactoring, das eine normale Entwicklungstaetigkeit darstellt, ist Reengineering eine Form der Software-
”Revolution”. Reengineeringprojekte sind sehr riskant und kostspielig. Der Nutzen des Reengineerings
ist normalerweise nicht so hoch wie erwartet. Wenn nach dem Reengineering schlieĂźlich die erforderlichen
Architekturaenderungen statt.nden, kann dies zu spaet sein. Trotz der enormen in das Projekt
gesteckten Bemuehungen erfuellen die Resultate des Reengineerings normalerweise nicht die Erwartungen.
Es kann passieren, dass sehr bald ein neues, kostspieliges Reengineering erforderlich wird.
In dieser Arbeit werden das Problem der Softwareevolution und der Zerfall von Softwarearchitekturen
behandelt. Eine Methode wird vorgestellt, welche die Softwareentwicklung in ihrer entscheidenden
Phase, dem Architekturrefactoring, unterstuetzt. Die Softwareentwicklung wird sowohl in technischer
als auch organisatorischer Hinsicht unterstuetzt. Diese Arbeit hat neue Techniken entwickelt,
welche die Reverse-Engineering-, Architecture-Recovery- und Architecture-Redesign-Taetigkeiten unterst
uetzen. Sie schlaegt auch Aenderungen des Softwareentwicklungsprozesses vor, die fristgerechte Architekturrefactorings
erzwingen koennen und damit die Notwendigkeit der Durchfuehrung eines Architektur-
Reengineerings vermeiden.
In dieser Arbeit wird die Merkmalmodellierung als Hauptinstrument verwendet. Merkmale werden
genutzt, um die Abstraktionsluecke zwischen den Anforderungen der Problemdomaene und der Systemarchitektur
zu fuellen. Merkmalmodelle werden auch als erster Grundriss fr die Wiederherstellung
der verlorenen Systemarchitektur genutzt. Merkmalbasierte Analysen fuehren zu diversen, nuetzlichen
Hinweisen fuer den erneuten Entwurf (das Re-Design) einer Architektur. SchlieĂźlich wird die Merkmalmodellierung
als Kommunikationsmittel zwischen unterschiedlichen Projektbeteiligten (Stakeholdern)
im Verlauf des Softwareengineering-Prozesses verwendet und auf dieser Grundlage wird ein neuer
Anforderungsde.nitionsprozess vorgeschlagen, der die erforderlichen Architekturrefactorings erzwingt.The long-life software systems withstand many significant changes throughout their life-cycle in order
to follow the evolution of the problem domains. Usually, the software system architecture can not
follow the rapid evolution of a problem domain and with time, the diversion of the architecture in
respect to the domain features becomes prohibiting for software evolution. For avoiding this problem,
periodical refactorings of the system architecture are required.
Usually, architecture refactorings are postponed until the very last moment, because of the relatively
high risk involved and the lack of short-term profit. As a rule, the management is unwilling to accept
architecture refactorings unless they become absolutely necessary. The preferred way of working is to
add new system features in an ad-hoc manner and to keep the rule ”Never touch a running system!”.
The final result is an architecture decay. The need of performing small refactoring activities turns into
need for architecture reengineering. In contrast to refactoring, which is a normal evolutionary activity,
reengineering is a kind of software ”revolution”. Reengineering projects are risky and expensive. The
effectiveness of reengineering is also usually not as high as expected. When finally after reengineering
the required architecture changes take place, it can be too late. Despite the enormous invested efforts,
the results of the reengineering usually do not satisfy the expectations. It might happen that very
soon a new expensive reengineering is required.
This thesis deals with the problem of software evolution and the decay of software architectures.
It presents a method, which assists software evolution in its crucial part, the architecture refactoring.
The assistance is performed for both technical and organizational aspects of the software evolution.
The thesis provides new techniques for supporting reverse engineering, architecture recovery and redesigning
activities. It also proposes changes to the software engineering process, which can force
timely architecture refactorings and thus avoid the need of performing architecture reengineering.
For the work in this thesis feature modeling is utilized as a main asset. Features are used to fill the
abstraction gap between domain requirements and system architecture. Feature models are also used
as an outline for recovering of lost system architectures. Through feature-based analyses a number of
useful hints and clues for architecture redesign are produced. Finally, feature modeling is used as a
communication between different stakeholders of the software engineering process and on this basis a
new requirements engineering process is proposed, which forces the needed architecture refactorings
Using feature modeling for program comprehension and software architecture recovery
Abstract: The available evidence in a legacy software system, which can help in its understanding and recovery of its architecture are not always sufficient. Very often the system’s documentation is poor and outdated. One may argue that the most reliable resource of information is the system’s source code. Nevertheless a significant knowledge about the problem domain is required in order to facilitate the extraction of the system’s useful architectural information. In this approach feature modeling is introduced as an additional step in a system’s architectural recovery process. Feature modeling structures the system’s functionality and supports reverse engineering by detecting the relations between source code elements and requirements. Tracing these relations may lead to a better understanding of the program’s behavior and the recovery of various architectural elements. In this way, by providing a mapping between source code and features, the system’s feature model supports program comprehension and architectural recovery. The approach is developed as first part of a migration methodology towards a component-based architecture of legacy systems. Recovered information about features and architecture is collected in a repository to enable a refactoring as next step. The approach is currently applied in a large project for reengineering of an industrial Image Processing System
Modeling Variability for Object-Oriented Product Lines
Abstract. The concept of a software product line is a promising approach for increasing planned reusability in industry. For planning future requirements, the integration of domain analysis activities with software development for reusability turned out to be necessary, both from a process and from an economic point of view. In this context, variability of requirements in a domain is expressed by feature models. Feature models enable planning and strategic decisions both for architectural and for component development. By expressing feature dependencies, feature models are used to partition the architecture and the implementation. For industrial use, appropriate methods for modeling variability in requirements, design and implementation as well as tools for supporting feature models and for integrating them with other models are needed. The ECOOP workshop explored the possibilities and limitations of feature models and supporting methods. Its fully reviewed contributions aim at improving the feature model usage as well as the integration into the software development process. Improving industrial applicability of feature modeling and methods is an important goal. This paper provides a summary of the discussion and presents the major results as well as important questions and issues identified for future research